There is known an ACPI (Advanced Configuration and Power Interface) as a standard technique for abstracting an HW constituting a computer, such as a CPU (Central Processing Unit) or memory. Abstracting the HW using the ACPI allows an OS (Operating System) such as Linux, Windows (registered trademark) and the like to boot on a platform of any vendor.
Specifically, the abstraction of the HW is performed by defining a tree-structured virtual space called an ACPI tree and describing the HW constituting a system on the ACPI tree as a device object. In the description of the ACPI Tree, a language called ASL (ACPI Source Language) is used. For objects corresponding to individual HWs, a method returning corresponding HW configuration information is described.
In general, when a method in the ACPI is described using the ASL, a configuration is employed in which information is read out from the HW and returned to an OS. Then, an ACPI driver on the OS executes the method in the ACPI, whereby the OS recognizes the HW configuration. That is, the OS recognizes the HW configuration through the ACPI. A procedure in which the ACPI makes the OS recognize the HW configuration is as follows.
(1) Method in ACPI refers to HW configuration and acquires data.
(2) Method-based processing is performed for data acquired by method in ACPI.
(3) Data created by method in ACPI is returned to OS.
However, the components that play a role of making the OS recognize the HW configuration in a conventional system are only the HW and ACPI. Further, unlike high-level languages such as C language, the ASL for use in description of the ACPI tree has limitations in the description of data definition or loop control, so the ASL is not suitable for description of a complicated control program and large-scale development. Thus, the conventional technique has the following problems.
(1) For large-scale server development, ASL development scale becomes large. This is because the number of the HWs on the ACPI tree is increased.
(2) For large-scale server development, development efficiency may be lowered to lead to quality degradation. This is because the ASL has limitations in the description of data definition or loop control.
(3) When the HW is modified or replaced by new one in the development of a new model, the ASL needs to be also rewritten to make assets reusing difficult. This is because the ACPI describes codes for referring to the HW using the ASL.
(4) There are inefficient aspects in supporting a multi-OS platform. This is because there may be a case where the ACPI driver on the OS cannot interpret ASL descriptions, so that the ASL needs to be described so as to allow all the OSes to interpret the ASL descriptions, thereby requiring preliminary studies.(5) There is inconvenience in debugging. This is because debugging is generally performed on the OS in the conventional method in which the ACPI driver on the OS interprets the ASL. That is, if the OS cannot be booted, the ASL cannot be debugged.
In this connection, PTL 1 discloses a method of avoiding name collision in an ACPI control method. This method is executed by a computer for avoiding name collision in an ACPI control method and configured to acquire a first argument constituted by a unique identifier and prevent the use of the same identifier for different ACPI control methods, whereby the first argument is associated with a reserved name of an ACPI control method so as to avoid name collision to construct a unique identifier of a specific ACPI control method.